前言

在本系列文章初期，花了很多篇幅介紹有關於 Connection ID 的概念，今天的文章會來探討 Connection ID 在 Connection Migration 下運作的機制。

不更換 Connection 的隱憂

今天在進行連線遷移後如果一直使用同一個 Connection ID，可能會導致惡意的攻擊者找出不同 network path 與 Connection ID 的關聯，原則上我們希望第三方的監聽者沒有辦法透過 Connection ID 來得到任何有關於對端的資料，但如果連線遷移之後還是用同一組 Connection ID，是有可能讓攻擊者找到一定的規律。

因此 QUIC 實作上，每次觸發連線遷移的時候，都必須要設定一個新的 Connection ID，可以理解成一個 local address 就算視為同一個 Client 也必須要有不同的 Connection ID。

也可以想成，在任何一個時間點，端點都可以把 Destination Connection ID 設為一個新值(沒有在其他 Path 中出現過)。

今天 Client 做連線遷移的時候會出現地址轉過去的瞬間，會有不同 Source 出現的情況，這種時候第一個封包還是原本的 Connection ID，所以特定情況下的確會出現 Source 不同但有著相同 Connection ID 的封包，筆者這部份有點沒看懂.. 之後去研究一下幾個專案的實作後再補充說明。

筆者 RFC9000 中這個章節的敘述覺得有點抽象，這裡我認為要參考各個開源方案才能知道他們實作時是怎麼理解這個段落的，這邊放上這段的連結